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(54) Service and event synchronous/asynchronous manager 



(57) A service and event synchronous/asynchro- 
nous manager (SESAM) which provides a programmer 
interface to concurrency, dispatching and synchroniza- 
tion in an object oriented computing system. SESAM 
employs a high level framework which is operating sys- 
tem independent, uses threads for asynchrony and 
independence from operating systems which do not 
provide for asynchrony, supports a high level "wait-for- 
event" interface, provides portability of applications and 
provides synchronization of asynchronous functionality 
so as to support active object patterns as well as pas- 
sive object patterns within a single homogenous solu- 
tion. SESAM includes: (a) at least one dynamic slot 
providing asynchronous execution of user submitted 
functions; (b) at least one synchronous timer slot; (c) at 
least one asynchronous timer slot; (d) at least one 
exception slot for handling user defined system excep- 
tion callbacks; (e) at least one slot providing external 
event notification for user events; (f) a thread dis- 
patcher; (g) a pointer to a main operating system dis- 
patcher; ( h) a signaling dispatcher; (I) a thread 
manager for managing execution of threads; Q) mes- 
sage block memory for storage of message blocks; (k) a 
list of SynchHandles that return an error external event 
notification for user events; (I) an administrator for map- 
ping of SynchHandles to slot identifiers; and (m) a 
queue for blocked threads. 
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Description 

BACKGROUND OF THE INVENTION 

The present invention is directed to multi-programming systems on objected oriented platforms. More particularly, 
the invention is directed to threading control. 

As set forth in U.S. Patent No. 5,499,365, fully incorporated herein by reference, object oriented programming sys- 
tems and processes, also referred to as "object oriented computing environments," have been the subject of much 
investigation and interest. As is well known to those having skill in the art, object oriented programming systems are 
composed of a large number of "objects." An object is a data structure, also referred to as a "frame," and a set of oper- 
ations or functions, also referred to as "methods," that can access that data structure. The frame may have "slots," each 
of which contains an "attribute" of the data in the slot. The attribute may be a primitive (such as an integer or string) or 
an object reference which is a pointer to another object. Objects having identical data structures and common behavior 
can be grouped together into, and collectively identified as a "class." 

Each defined class of objects will usually be manifested in a number of "instances". Each instance contains the par- 
ticular data structure for a particular example of the object. In an object oriented computing environment, the data is 
processed by requesting an object to perform one of its methods by sending the object a "message". The receiving 
object responds to the message by choosing the method that implements the message name, executing this method 
on the named instance, and returning control to the calling high level routine along with the results of the method. The 
relationships between classes, objects and instances traditionally have been established during "build time" or genera- 
tion of the object oriented computing environment, i.e.. prior to "run time" or execution of the object oriented computing 
environment. 

In addition to the relationships between classes, objects and instances identified above, inheritance relationships 
also exist between two or more classes such that a first class may be considered a "parent" of a second class and the 
second class may be considered a "child" of the first class. In other words, the first class is an ancestor of the second 
class and the second class is a descendant of the first class, such that the second class (i.e., the descendant) is said 
to inherit from the first class (i.e., the ancestor). The data structure of the child class includes all of the attributes of the 

parent class. . , 

Object oriented systems have heretofore recognized Versions" of objects. A version of an object is the same data 
as the object at a different point in time. For example, an object which relates to a "work in progress", is a separate ver- 
sion of the same object data which relates to a completed and approved work. Many applications also require historical 
records of data as it existed at various points in time. Thus, different versions of an object are required. 

Two articles providing further general background are E.W. Dijkstra. The Structure of "THE" Multi programming 
System Communications of the ACM, Vol. 11, No. 5, May 1968, pp. 341-346, and C.A.R. Hoare, Monitors: Operating 
Systems Structuring Concepts, Communications of the ACM. Vol. 17. No. 10. October, 1974. pp. 549-557, both of which 
are incorporated herein by reference. The earlier article describes methods for synchronizing using primitives and 
explains the use of semaphores while the latter article develops Brinch-Hansen's concept of a monitor as a method of 
structuring an operating system. In particular, the Hoare article introduces a form of synchronization for processes and 
describes a possible method of implementation in terms of semaphores and gives a proof rule as well as illustrative 
examples. 

The following terms are or may be used herein: 

. Thread - a parallel execution unit within a process. A monitor synchronizes, by forced sequentialization, the parallel 
access of several simultaneously running threads, which all call up functions of one object that are protected 
through a monitor. 

. Synchronizations-Primitive - a means of the operating system for reciprocal justification of parallel activities. 

• Semaphore - a Synchronizations-Primitive for parallel activities. 

• Mutex - a special Synchronizations-Primitive for parallel activities, for mutual exclusion purposes, it includes a crit- 
ical code range. 

• Condition Queue - an event waiting queue for parallel activities referring to a certain condition. 

• Gate Lock - a mutex of the monitor for each entry-function, for protection of an object by allowing only one parallel 
activity at a time to use an Entry-Routine of the object. 

• Lono Term Scheduling - longtime delay of one parallel activity within a condition queue or event waiting queue for 
parallel activities. 

Broker - a distributor. 

The following acronyms also are or may be used herein: 
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AFM . 

SESAM 

PAL 

API 

IDL 

ATOMIC 



XDR 

I/O 

IPC 

CSA 

SW 



Asynchronous Function Manager 

Service & Event Synchronous Asynchronous Manager 

Programmable Area Logic 

Application Programmers Interface 

Interface Definition Language 

Asynchron Transport Optimizing observer-pattern-like system supporting several Modes (client/server - 
pusrVpull) for an IDL- less Communication subsystem (This is the subject of commonly assigned application, 
Attorney Docket No. GR 96 P 3109 E, incorporated herein by reference) 
External Data Representation 
Input/Output 

Inter Process Communication 

Common Software Architecture (a Siemens AG computing system convention) 
Software 



15 SUMMARY OF THE INVENTION 

The present invention provides a service and event synchronous/asynchronous manager (SESAM) which provides 
a programmer interface to concurrency, dispatching and synchronization in an object oriented computing system. The 
programmer thus is relieved from bothering with low level thread details. The interface serves as a gate to synchro- 
v nous/asynchronous functions. 

An object of SESAM is to provide a high level framework which is operating system independent. 

An object of SESAM is to provide usage of threads for asynchrony and independence from operating systems 
which do not provide for asynchrony. 

An object of SESAM is to provide support for a very high level H wait-for- event" interface which makes it possible for 
25 a single high level "applications- mainloop" to capture all low level operating system dependent event dispatching as 
well as high level application event dispatching. 

An object of SESAM is to provide portability for applications and operating systems. 

An object of SESAM is to provide synchronization of prior asynchronous functionality so as to support active object 
patterns as well as passive object patterns within a single homogenous solution. 
30 In an embodiment, the invention provides an object oriented computing system programmer interface system, com- 

prising: 



(a) at least one dynamic slot providing asynchronous execution of programmer submitted functions; 

(b) at least one synchronous timer slot; 
35 (c) at least one asynchronous timer slot; 

(d) at least one exception slot for handling programmer defined system exception callbacks; 

(e) at least one slot providing external event notification for programmer events; 

(f) a thread dispatcher; 

(g) a main dispatcher; 

a (h) a signaling dispatcher; 

(i) a thread manager for managing execution of threads; 
(j) message block memory for storage of message blocks; 

(k) a list of SynchHandles that return an error external event notification for user events; 
(I) an administrator for mapping of SynchHandles to slot identifiers; and 
45 (m) a queue for blocked threads. 

In an embodiment, the invention provides that a plurality of dynamic slots are provided, and the dynamic slots are 
configured to assume the following states: 

so an initial state when nonsignalled and not yet used; 
a queued state when nonsignalled and in use; 

a started state when nonsignalled and in use and a submitted function is being executed; 
a finished state when signalled and in use and execution of a submitted function is complete; 
a callback active (CbActive) state when signalled and in use and a submitted function is being executed; and 
55 an idle state when signalled and no longer in use. 

In an embodiment, the invention provides that the main dispatcher is provided by way of a pointer to an operating 
system dispatcher. 
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In an embodiment, the invention provides an object oriented computing system programmer interface system, com- 
prising: 

means for centrally dispatching threads and providing runtime configurable delivery of event handlers; 
means for interrupting execution of event handlers; 
means for blocking warts for events in event handlers; 

means for executing functions asynchronously with respect to events occurring external to the interface system; 
and 

means for executing asynchronous timer handlers in parallel to other running event handlers. 

In an embodiment, the invention provides an object oriented computing system programmer interface system, com- 
prising: 

means for interrupting callback driven systems, including interrupting callbacks themselves; 

an asynchronous dispatcher ; 

a synchronous dispatcher; 

an asynchronous signaling dispatcher; 

a thread manager; and 

a plurality of different types of slots used for administrating activities assigned to them. 

In an embodiment, the invention provides that the plurality of different types of slots comprises: 

at least one dynamic slot which administrates asynchrony for an application programmer; 

at least one synchronous timer slots which administrates synchronous timers; 

at least one asynchronous timer slot which administrates asynchronous timers; 

at least one exception slot which administrates user defined system exception callbacks; and 

at least one generic slot which administrates waitFor...O functionality for user events. 

These and other features of the invention are discussed in greater detail below in the following detailed description 
of the presently preferred embodiments with reference to the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates a hardware and software environment. 

Figure 2 illustrates the main components of an object-oriented program from Figure 5 of U.S. Patent No. 
5,313,629. 

Figure 3 illustrates an example of an inheritance hierarchy to an object oriented platform. 

Figure 4 illustrates an environment schematic for SESAM. 

Figure 5 illustrates basic components of SESAM. 

Figure 6 illustrates principles of executing a user function asynchronously. 

Figure 7 illustrates transition states for a dynamic slot. 

Figure 8 illustrates asynchronous execution of a function with a callback mode. 

Figure 9 illustrates a sequence of activities related to one shot timers. 

Figure 1 0 illustrates a sequence of activities related to interval timers. 

Figure 1 1 illustrates a timer callback invocation delay due to invocation of another callback. 

Figure 1 2 illustrates suspension of a timer slot. 
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Figure .1 3 illustrates a signaling state of a interval timer slot. 

Figure 14 illustrates a stack of user defined system exception handlers separated by invocation modes (within one 
slot i.e., for one exception). 

Figure 15 illustrates parallel execution of exception handlers for the same exception. 

Figure 16 illustrates the process of serializing exception handler routines by invoking them via a dispatcher (using 
callback modes CbSyncMainDispatch, CbAsyncMainDispatch_SyncSesamDisptach). 

Figure 17 illustrates parallel execution of exception handlers for different exceptions when using callback mode 
CbAsyncMainDispatch_AsyncSesamDispatch. 

Figure 18 illustrates a signaled stated of a exception slot. 

Figure 19 illustrates interconnection between CsaConnectable a generic slot and bcs object. 
Figure 20 illustrates interconnection between CsaRemote, a generic slot and bcs object. 
Figure 21 illustrates the signaled state of a CsaConnectable. 
Figure 22 illustrates the signaled state of a CsaRemote in pull mode. 
Figure 23 illustrates the signaled state of a CsaRemote in push mode. 
COPENDING APPLICATIONS 

The following commonly assigned copending applications are incorporated herein by reference: 
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Application NUMBER 


Filing Date 


Attorney Docket No. 




MONITOR SYSTEM FOR SYNCHRONIZATION 
OF THREADS WITHIN A SINGLE PROCESS 






GR96P3106E 


35 


ASYNCHRONOUS TRANSPORT OPTIMIZING 
OBSERVER-PATTERN LIKE SYSTEM SUPPORT- 
ING SEVERAL MODES FOR AN INTERFACE 
DEFINITION LANGUAGE-LESS COMMUNICA- 
TION SUBSYSTEM 






GR96P3108E 


W 


SOFTWARE ICS FOR HIGH LEVEL APPLICA- 
TION FRAMEWORKS 






GR 96 P 3109 E 
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DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS 



Again, as set forth in U.S. Patent No. 5,499,365, fully incorporated herein by reference, in an object oriented com- 
puting environment, work is accomplished by sending action request messages to an object which contains data. The 
object will perform a requested action on the data according to its predefined methods. Objects may be grouped into 
object classes which define the types and meanings of the data, and the action requests (messages), that the object 
so will honor. The individual objects containing data are called instances of the class. 

Object classes can be defined to be subclasses of other classes. Subclasses inherit all of the data characteristics 
and methods of the parent class. They can add additional data and methods and they can override or redefine any data 
elements or methods of the parent class. 

Figures 1, 2 and 3 are reproduced from U.S. Patent No. 5,499,365. The following description relating thereto is 
55 derived from that patent. 

Referring now to Figure 1 . a hardware and software environment is illustrated. In Figure 1 , there is shown an object 
oriented computing environment 11 operating on one or more computer platforms 12. It will be understood by those 
having skill in the art that computer platform 12 typically includes computer hardware units 13 such as a central 
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processing unit (CPU) 14, a main memory 15 and an input/output (I/O) interface 16, and may include peripheral. com- 
ponents such as a display terminal 21, an input device 22 such as a keyboard or a mouse, nonvolatile data storage 
devices 23 such as magnetic or optical disks, printers 24 and other peripheral devices. Computer platform 12 also typ- 
ically includes microinstruction codes 26 and an operating system 28. 

As shown in Figure 1, object oriented computing environment 11 operates on computer platform 12. It will be 
understood by those having skill in the art that object oriented computing environment may operate across multiple 
computer platforms. Object oriented computing environment 1 1 is preferably written in the C++ computer programming 
language. The design and operation of computer platforms and object oriented computing environments including that 
of an object manager, are well known to those having skill in the art and are described, according to U.S. Patent No. 
5,499,365, in U.S. Patent No. 5,265,206 issued November 23, 1993 to Abraham, et al., entitled "A Messenger and 
Object Manager to Implement an Object Oriented Environment"; and U.S. Patent No. 5.161 .225 to Abraham, et al., enti- 
tled "Persistent Stream for Processing Time Consuming and Reusable Queries in an Object Oriented Database Man- 
agement System; U.S. Patent No. 5,151,987 to Abraham, et al., entitled "Recovery Objects in an Object Oriented 
Computing Environment"; and U.S. Patent No. 5, 1 61 .223 ti Abraham, entitled "Resumeable Batch Query for Processing 
Time Consuming Queries in an Object Oriented Database Management System", all assigned to IBM, the disclosures 
of which are hereby incorporated herein by reference, and in numerous textbooks such as Object Oriented Software 
Construction by Bertrand Meyer, published by Prentice Hall in 1988, the disclosure of which is incorporated herein by 
reference, as are the publications referred to above in the Background of the Invention section of this specification. 

Referring now to Figure 2, which is a reproduction of Figure 5 of U.S. Patent No. 5,313,629, the main components 
of an object oriented program (11, Figure 1) will be described. A detailed description of the design and operation of an 
object oriented program is provided in "Object Oriented Software Construction", by Bertrand Meyer, published by Pren- 
tice Hall in 1988, the disclosure of which is incorporated herein by reference. 

Referring to Figure 2, a typical object oriented computing environment 11 includes three primary components: a 
Messenger 51, and Object Management Table 52 and a Loaded Classes Table 53. The Messenger 51 controls com- 
munication between calling and called messages, Object Management Table 52 and Loaded Classes Table 53. Object 
Management Table 52 contains a list of pointers to all active object instances. The Loaded Classes Table 53 contains 
a list of pointers to all methods of active object classes. 

Operation of the Object Oriented Program 1 1 will now be described for the example illustrated in Figure 2 f in which 
Methods A (block 54) of an object sends a message to method B (block 55) of an object. Method A sends a message 
to Method B by calling Messenger 51 . The message contains (1 ) an object reference of the instance to receive the mes- 
sage. (2) the method the object instance is requested to perform on the data it encapsulates, and (3) any parameters 
needed by the receiving method. Messenger 51 obtains a pointer to the data frame 56 of the instance object specified 
by Method A, by searching Object Management Table 52 for the instance object. If the specified instance object cannot 
be found, Object Management Table 52 adds the instance object to the table and calls the instance to materialize its 
data from the database. Once in the instance table, Object Management Table 52 returns the pointer to the materialized 
instance object 

Messenger 51 then obtains the address of Method B from the Loaded Classes Table 53. If the instance s class is 
not loaded, the Loaded Classes Table 53 will load it at this time to materialize its data. The Loaded Classes Table 53 
searches for the specified method (Method B) and returns the address of the method to Messenger 51 . 

The Messenger 51 then calls Method B, passing it a system data area and the parameters from the call made by 
Method A including the pointer. Method B accesses the data frame 56 using the pointer. Method B then returns control 
to the Messenger 51 which returns control to Method A. 

Figure 3 illustrates an example of an inheritance hierarchy to an object oriented computing platform. As shown, 
three object classes are illustrated for "salesperson", "employee" and "person", where a salesperson is a "kind of" 
employee, which is a "kind of person. In other words, salesperson is a subclass of employee and employee is the 
superclass of salesperson. Similarly, employee is the subclass of person and person is the superclass of employee. 
Each class shown includes three instances. B. Soutter, W. Tipp and B.G. Blue are salespersons. B. Abraham, K. Yates 
and R. Moore are employees. J. McEnroe. R. Nader and R. Reagan are persons. In other words, an instance is related 
to its class by an "is a" relation. 

Each subclass "inherits" the frames and methods of its super-class. Thus, for example, a salesperson frame inherits 
age and hire date objects from the employee's superclass as well as promote methods from the employee superclass. 
Salesperson also includes a unique quota attribute and a pay commission method. Each instance can access all meth- 
ods and frames of its superclass, so that, for example, B.G Blue can be promoted. 

As set forth above, the invention, SESAM, is designed to offer to an application programmer an interface to concur- 
rency, dispatching and synchronization, thus relieving the application programmer from bothering with low level thread 
details. In this way SESAM serves as a gate to synchronous and asynchronous function behavior. 

With reference to Figure 4, it can be seen that within an operating process 100 an application programmer working 
at application level 102 registers services with a main dispatcher 104 upon process startup. However, whenever asyn- 
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" chrony is required within the registered services, the services can make use of SESAM 106. In that case, asynchronous 
callback scheduling will be serviced by a SESAM dispatcher 108. This includes all user callbacks registered to be exe- 
cuted asynchronously. 

Because the main dispatcher 104 and SESAM dispatcher 108 both will execute user callback code that may block 
5 the main dispatcher 104, a third dispatcher, SESAM Signaling Dispatcher 110, is included and made responsible for 
ensuring that timer scheduling and communication events are not delayed by user code. User callbacks are registered 
with SESAM and it internally will notify the correct dispatchers to schedule the callbacks. System exceptions are han- 
dled on a low level within the main thread that in turn will notify the dispatchers or threads to execute the exception call- 
backs. 

10 To understand the foregoing, SESAM functionality will be described. 
HEURISTICS 

Events always occur asynchronously. Depending on the semantics of the program, it is desirable to either be 
is informed asynchronously (via registered callbacks) or synchronously (by explicitly querying as to whether or not an 
event has occurred). Another important object is synchronization to asynchronously incoming events (i.e.. events com- 
ing in asynchronously), i.e. the programmer wants to do some processing and at a certain point in time he wants to be 
blocked until the next event or a logical combination of events occurs. 

20 FUNCTIONALITY 

SESAM is intended to support ASYNC-ASYNC programming models as well as ASYNC-SYNC programming mod- 
els. ASYNC-ASYNC programming models are preferred if asynchronous events should be promoted to registered con- 
sumers asynchronously (push mode, supplier triggered). ASYNC-SYNC programming models are preferred if the 
25 consumer decides at what time an event should be triggered (consumer driven, pull mode). 

SESAM is designed to offer a homogenous and comfortable interface to the following functions: 

execution of functions asynchronously (i.e. execution of a function in a separate thread) (Asynchronous Function 
Manager ■ AFM) 
30 • scheduling of synchronous timers 
scheduling of asynchronous timers 
handling of exceptions 

providing general synchronization interface for communication events 
watting for a list of events 
35 • synchronizing with multiple dispatchers 

Each of the above mentioned features make internal use of "slots". Slots in SESAM are administrative entities that 
keep track of the state or status of activities assigned to the slots. These slots are tailored for special purposes (not vis- 
ible to the user) and are identified by synchronization handles which are visible to the user and referred to as Synch- 
ro Handles. These SynchHandles offer a homogenous view to the features supplied by SESAM. The lifecycle of 
SynchHandles is bound to the lifecycle of the SESAM object. 

For debugging and/or support purposes, it is possible to give each slot a name (not checked for uniqueness). That 
way, important information can be retrieved about a slot at runtime (e.g. type, name, state, etc.). 

Functions that are submitted to SESAM for invocation may depend on special thread specific data settings. But 
45 because SESAM provides an execution agent (for threads) for internal function invocation, hooks are provided allowing 
the application programmer to set and save thread specific data before and after function invocation. Hooks can be 
specified by the application programmer upon invocation of selected SESAM API functions using a Hooklnlb structure. 
The Hooklnfo structure allows the specification of four functions along with parameters for each of the functions. 

Figure 5 shows the basic components of SESAM. Attached as an Appendix hereto is the header file of the C++ 
so class CsaSESAM which implements the components described herein. Reference should also be made to the com- 
monly assigned copending applications incorporated herein by reference for further information regarding other items 
used by SESAM such as the classes CsaConnectable and CsaRemote, among others. In particular, reference should 
be made to parallel application, Attorney Docket No. GR 96 P 3108 E. 

As illustrated, SESAM contains 5 different types of slots, each type tailored to its specific purpose: 

55 

Dynamic slots 200 handle asynchrony for the application programmer, 
Timer slots 202 (synchronous), handle synchronous timers, 
Timer slots 204 (asynchronous), handle asynchronous timers, 
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Exception slots 206 handle user defined system exception callbacks and 
. Generic Slots, offering the comfort of waitFor...O functionality for user events, i.e., external event notification. 

Slots eventually have to make use of threads and schedule callbacks according to a user selected invocation mode. 
Therefore, a thread manager 21 0 provides a thread factory and the several dispatchers 1 04, 1 08 and 1 1 0 as discussed 
above, are responsible to invoke the callbacks with the correct scheduling. With respect to the main dispatcher 104. as 
illustrated, SESAM provides a pointer 104A thereto as the main dispatcher 104 is not a part of SESAM, per se. 

SynchHandles identify activities within SESAM regardless of the slot type to which they are assigned. Since all 
activities serviced by SESAM are referenced through SynchHandles, a homogenous view to different slots and activi- 
ties is provided. Internally slots are sequentially numbered at creation time. Especially because slots are re-usable (i.e. 
if they have finished an activity, they are then able to start processing the next request), a mapping between the actual 
SynchHandle and the internal slot identification (ID) processing this activity is required. This is the task of a slot admin- 
istrator 212. 

A pool of message blocks allows the usage of an efficient internal message passing mechanism. Message diocks 
can also be re-used. Available message blocks are kept in a message block reservoir 214. 

Using SynchHandles in the wartFor...() interface from activities that were e.g. removed or that were not successfully fin- 
ished results in an error. To, on the one hand, allow the re-usability of slots that were assigned to such failing activities, 
and, on the other hand, to not lose the history for such a SynchHandle, a list 216 of "invalid" SynchHandles thus is 
stored within SESAM. . . 

Finally, there is an administrator 218 for threads currently blocked in a waitFor...O call. This administrator 218 is 
responsible for unblocking a thread if the condition is true for which the thread was waiting. 

ASYNCHRONOUS EXECUTION OF USER FUNCTIONS: THE AF M 

SESAM provides concurrency mechanisms to the application programmer. This allows programmers to execute 
functions in parallel, i.e. these functions are executed asynchronously with respect to each other (e.g. in order to make 
efficient parallel use of several processing units). 

Dynamic slots are used within SESAM to implement asynchrony. 

The user specified function will be invoked in a thread asynchronously to the thread that has submitted this func- 
tion The execution state is monitored automatically and can be queried at any time. Synchronization on the termination 
of asynchronously executed functions is provided as well as the activation of user defined callbacks upon termination 
of asynchronous functions. The callback can be invoked synchronously from the main dispatcher 104 or asynchro- 
nously from the SESAM dispatcher 108 or a separate thread. 

Arguments can be supplied to the user defined function. The return value of the user defined function is automati- 
cally supplied as an argument to the callback. The callback cannot return a value. 

Figure 6 illustrates a basic principle of executing a user function asynchronously. 

As illustrated, a user supplied synchronous function from a main thread is supplied with a user-callback request to 
be executed in a separate thread, i.e.. the synchronous function will be executed asynchronously to the main thread. 

When the asynchronous execution of the synchronous function is finished, the user specified callback function is 
invoked. The return value of the synchronous function is passed to the callback as an argument. 

The thread of control in which the callback should be executed must be selected prior to invocation. Choices for 
such control are: 

Main dispatcher thread 

• SESAM dispatcher thread 

• asynchronous thread that has already executed the synchronous call. 

Though the callback mechanism seems to be a reasonable way to process the return value of the asynchronously 
executed function, sometimes there are reasons to process the results at a latter point in time (synchronously in control 
flow). For example, if the user did not specify a callback, the return value of the asynchronously executed function can 
be stored internally until explicitly queried by the user. 

STATES AND TRANSITION OF A DYNAMIC SLOT 

When querying the status of a dynamic slot the below listed states can be returned: 

Initial - non-signaled, slot is in an initial state and not yet used. 

Queued - non-signaled, slot is in use, a function was submitted to the AFM in order to be executed in the thread 
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Started - 
Finished - 
CbActive - 
Idle - 



that is assigned to this slot. Thread was successfully created. 

non-signaled, slot is in use, the thread has started to execute the user function. 

signaled, slot is in use, the user function is finished. 

signaled, slot is in use, callback function is running. 

signaled, slot is unused, can be reused again. 



Figure 7 shows state transitions for a dynamic slot. In Figure 7, the encircled number corresponds to state transi- 
tions referred to next in parentheses. 

As illustrated, upon creation, a slot is in an "Initial" state 300 (indicating that it was never used before and ail it's 
io members contain invalid values). If a function with argument and callback is submitted via the "activateO" interface to 
SESAM, the slot will enter the "Queued" state 302, i.e., undergo state transition (1). After the worker thread is created 
and has started execution of the user function, the slot assumes a "Started" state 304, i.e. it undergoes state transition 
(2). When the user function returns, the slot enters a "Finished" state 306, i.e., it undergoes state transition (3). 

Thereafter, when callback is activated, the slot state will turn to a "CbActive" state 308, i.e., it undergoes state tran- 
is sition (4). As soon as the callback returns, the slot reaches an "Idle" state 310, i.e. , it undergoes state transition (5). With 
a new activation, the slot again will enter the "Queued" state 302, i.e., it undergoes state transition (1). 

The illustrated state transition (6) from the "Finished" state 306 to the "Idle" state 310 is triggered when the user 
has not specified a callback function and has specified that the return value of the user function should be kept in the 
dynamic slot. The slot remains in the "Finished" state 306 until the return value for this dynamic slot is explicitly queried 
v by the user. After a first query, the slot state changes to the "Idle" state 310. If the user does not specify a callback and 
does not want to keep the return value of the user function, then the transition (6) is performed automatically as soon 
as the slot has reached the "Finished" state 306. 

Figure 8 shows execution of a function asynchronously with callback mode CB_ASYNC_MD_ASYNC_AD. 

The circled numbers correspond to the numbers in parenthesis in the next paragraph and to the circled numbers in 
25 the state transition diagram for SESAM's status register states. 

As shown in Figure 8, when a Thread A submits a function and a callback to SESAM, i.e., transistors (1, 7) are to 
occur, internally SESAM needs a dynamic slot to satisfy this request. If no dynamic slot exists or is available then implic- 
itly a new dynamic slot is created. When a function is submitted to a dynamic slot, a new thread is created (hidden from 
the user) that will start executing the submitted function, i.e., undergo transition (2). When the user function has 
30 returned, the slot state will change automatically to a "Finished" state, i.e., undergo transition (3). If a callback was spec- 
ified, it is executed next, i.e., transition (4) occurs. The callback may either be executed in the same thread as the user 
function (as shown) or it is scheduled with the dispatcher to be run next in the dispatcher thread (not shown). When the 
callback is over, the slot status is again changed to "Idle," i.e., transition (5) takes place. All slot status changes are done 
implicitly (hidden from the user). With submission of a function, the dynamic slot is in a non-signaled state. At the end 
35 of the execution of the user function, the dynamic slot is automatically set to a signaled state (releasing threads that 
have been waiting for this slot to be in the signaled state, e.g. thread A). 

Callback invocation mode 

» If a callback is specified, one out of three callback invocation modes must be selected. These modes are shown in 
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Table 1. Callback invocation modes. 



45 

Control Interlace 

Dynamic slots can be suspended, resumed and removed. The effect on the execution depends on the callback 
invocation mode and point in time when the command was issued. 
so Dynamic slots are suspended when: 

• callback mode CbSyncMainDispatch or CbAsyncMainDispatch_SyncSesamDispatch is invoked and 

As long as the asynchronous thread exists, suspend will do a thread suspend. 
55 . if the thread no longer exists, a suspend flag will be set in the dynamic slot. If the callback is scheduled to run 
by the dispatcher and the suspend flag is set, callback invocation is skipped, i.e. the notification is lost. After- 
wards the dynamic slot is automatically removed as if the notification would have been done. If callback is 
already active then the setting of suspend flag will be ignored. 



10 



BNSDOCID: <EP 08170iaA2 I > 



EP 0 817 018 A2 

- . If callback is already finished, then the respective dynamic slot does not exist any longer and suspend returns 
an error. 

callback mode CbAsyncMainDispatch_AsyncSesamDispatch is invoked and 

5 

Since the thread exists for the complete execution time of user function as well as callback function the thread 
will be always suspended resulting in either suspending user function or suspending callback. In this case noti- 
fication does not get lost 

10 • KeepRetVal or DismissRetVal is invoked and: 

As long as the asynchronous thread exists, suspend will do a thread suspend. 

If mode DismissRetVal was specified the slot will not exist longer as the thread exists and therefore trying to 
suspend the slot will return an error. If mode KeepRetVal was specified and the thread does not exist any 
is longer a suspend flag will be set in the dynamic slot (if still existing). When a programmer tries to retrieve the 

return value of a suspended slot he will receive an error message. Retrieval of return value is only possible if 
slot is not suspended. 

Dynamic slots will be resumed if: 

The thread was suspended. 

The slot still exists, then the suspend flag will be reset. 
The slot does not exist, Resume will then return an error code. 

25 Dynamic slots will be removed when: 

callback mode CbSyncMainDispatch or CbAsyncMainDispatch_SyncSesamDispatch is invoked and: 

As long as the asynchronous thread exists, the thread will be killed and the according event handler has to be 

30 removed from the dispatcher. 

If thread does not exist any longer a remove flag will be set in the dynamic slot. If the callback is scheduled to 
run by the dispatcher and the remove flag is set, callback invocation is skipped, i.e. the notification is lost. After- 
wards the dynamic slot is automatically removed as if the notification would have been done. If callback is 
already active then the setting of remove flag will be ignored. 

35 - If callback is already finished then the according dynamic slot does not exist any longer and remove returns an 
error. 

callback mode CbAsyncMainDispatch_AsyncSesamDispatch: 

io - Since the thread exists for the complete execution time of user function as well as callback function the thread 
will be always killed resulting in either killing the user function or killing the callback. 

KeepRetVal, DismissRetVal: 

45 As long as the asynchronous thread exists, remove will do a thread kill. 

If thread does not exist and slot still exists, remove will free the slot. If slot does not exist any more remove will 
return an error. 

Remove will abort an action at any point without taking care about semantics, i.e. incomplete transactions may 
so occur. 

3iqncMed state 

A dynamic slot will be in a signaled state whenever the user function has returned within the asynchronous thread. 
55 A signaled state cannot be reset and changed by suspending/removing the slot afterwards. Using the SynchHandle of 
a dynamic slot that has been removed before the asynchronous function has been finished within a waitFor...Q call will 
result in an error. Using SynchHandle of a dynamic slot that has been removed after the asynchronous function has 
been finished in a waitFor...Q call will work normally. Any waitFor...Q calls that are waiting for the completion of an asyn- 
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chronous function in any logical combination will be aborted and return an error at that moment when ihe according 
dynamic slot is removed. 

The "activateO'' interface allows the specification of hooks to be invoked before the user function "beforeFunc" is 
invoked, after the user function "afterFunc" has returned, before the callback "beforeCb" is activated, and after the call- 
back "afterCb" has returned- Functions "beforeCb" and "afterCb" are only invoked if a callback was specified. 

The functions "beforeFunc" and "afterFunc" are invoked in the same thread as the function itself. The functions 
"beforeCb" and "afterCb" are invoked in the context of the thread that will execute the callback function itself. 

SCHEDULING TIMERS 

Timers are used to start an activity after a specified time delay. Such an activity is most often the invocation of a 
user specified function. The user function is scheduled to run after the timer has expired. Timer slots 202 and 204 (Fig- 
ure 5) are used within SESAM to support timer controlled activities. 

SESAM supports two modes of scheduling timers (i.e. scheduling user functions): synchronously and asynchro- 

nOU Vv1th respect to synchronous scheduling of timers, after the timer has expired, the main dispatcher 104 is informed 
to execute the user function as soon as possible. This may take a while if the dispatcher 104 is still executing another 
user function. If several timers were scheduled to expire at the same time the registered user functions are executed 
sequentially resulting in an increasing delay to the original desired point in time where the function was intended to run. 

With respect to asynchronous scheduling of timers, after the timer has expired, the SESAM dispatcher 108 is 
informed to execute the user function as soon as possible. This may take a while if the dispatcher 1 08 is still executing 
another asynchronously registered callback function: H several asynchronous timers were scheduled to expire at the 
same time the registered user functions are executed sequentially resulting in an increasing delay to the original desired 
point in time where the function was intended to run. But asynchronous timer callbacks will be executed asynchronously 
to functions that are executed in the main thread. 

Figure 9 illustrates a sequence of activities related to one shot timers. As illustrated: 

(1 ) A timer will be instantiated by supplying a time after which it should expire and a callback function to be invoked 
upon timer expiration. 

(2) Thereafter, when the timer expires, it notifies the specified dispatcher to invoke the callback. 

(3) Then the callback will be invoked by the dispatcher. The delay between expiration (2) of timer and invocation (3) 
of callback depends on how busy the dispatcher is with invoking other callbacks. 

When specifying an interval timer two values must be supplied: 

• a delay value: the time after which the timer expires for the first time after activation. 

• an interval value: this time value will be the delta time between two succeeding timer expirations. 

Figure 10 illustrates a sequence of activities related to interval timers. As illustrated. H an interval timer expires 
before the according callback is invoked, the expiration events will be queued internally. 

Figure 1 1 illustrates a scenario where a timer callback that was triggered at a point in time (A) cannot be invoked 
due to a busy dispatcher. Before the callback is invoked the timer expires a second time and only then is the dispatcher 
able to start the callback. But the number of timer expirations and invoked callbacks is identical again. 

Control Interface 

In SESAM it is possible to suspend, resume and remove timer slots. Suspending a timer slot will result in suppress- 
ing the invocation of a callback at that time. Suspending a timer slot will not change its signaled state behavior. Resum- 
ing a timer slot will result in enabling the callback invocation again. Removing a timer slot will delete the timer slot within 
SESAM. If a timer slot is removed, its SynchHandle will be invalid for waitFor...O invocations in which case an error will 
be returned. 

Figures 12 and 13 illustrate the effects of suspending of a timer slot. Figure 12 illustrates the foregoing suppression 
of a callback. Figure 1 3 illustrates the signaling state of an interval timer slot. 

Signaled state 

If the timer is a one shot timer, its slot will be in a signaled state after the timer has expired (regardless whether the 
timer is suspended at that time or not), and this state can not be reset. If the timer is an interval timer, the signaled state 
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is only pulsed &t every expiration time (regardless whether the time is suspended at that time or not). If a timer is 
removed, its slot state is invalid, i.e. it cant be used in a waitFor...O call any more. Any waitFor...() calls that are waiting 
for a timer event in any logical combination will be aborted and return an error at that moment when the appertaining 
timer slot is removed. 

5 An "addTlmerO" interface allows the specification of hooks to be invoked before the timer callback is activated 

(beforeCb component) and after the timer callback has returned (afterCb component). These hook functions are 
invoked in the same thread in which the timer callback is invoked. 

HANDLING SYSTEM EXCEPTIONS 

10 

If a process hangs completely at the user level (e.g., it is hung up in an endless loop) it may be desirable to issue 
to this process a high priority message that the process cannot ignore. Such high priority messages are called excep- 
tions. On UNIX systems, exceptions are implemented as signals. A programmer can register callbacks for such excep- 
tions that are to be invoked when an exception occurs in order to be able to respond to the exception. Exception slots 

is are used in SESAM to implement this feature. 

To that end, the main thread is configured to always receive the system exceptions (signals). A default exception 
handler will be started upon reception of an exception. This default handler is responsible for invoking all registered call- 
backs according to the selected invocation mode. Supported invocation modes for callbacks are identical to those for 
the dynamic slots (i.e., CBSyncMainDispatch, CbAsyncMainDispatch_SyncSesam Dispatch, CbAsyncMainDispatch_- 

?o AsyncSesamDispatch). 

For each supported exception a well known unique SynchHandle exists. It is possible to either register callbacks 
with different invocation modes (like those for callbacks to dynamic slots) to an exception or to explicitly wait for the next 
exception. The notification mechanisms also are identical to those used for the dynamic slots. Since system exceptions 
in UNIX are implemented using signals some facts have to be considered: 

25 

physically, the system only knows one exception handler per exception (not a stack of handlers). SESAM provides 
a separate stack of exception handlers for each invocation mode. But, any third party library may install its own 
exception handler with the system forgetting about the previously installed SESAM exception handler. This can 
lead to lost exceptions for SESAM registered callbacks. To avoid such a non-cooperative behavior, a re-install 
30 method is provided by SESAM that allows the chaining of third party handlers along with their own callback routines 
upon invocation. 

at installation time of a signal handler, it must be defined what happens with system calls that are interrupted by an 
exception signal, i.e. whether they should return an error (notifying the user about the interrupt) or they should be 
internally restarted. Conflicting settings of third party library handlers cannot be solved, i.e., if one library depends 
35 on the interrupt of system calls and the other does not (within the same process) either the first library component 
may hang (since it never left the system call, if restart was selected as desired by the second library) or the second 
library will return errors (since it never expected to have system calls being interrupted, if no restart was selected 
as desired by the first library). 

Third party libraries may not uninstall signal handlers at runtime. Most probably they will uninstall their default signal 
40 handler. 

Third party exception handlers that are found during installation of the default handler will be invoked on the signal 
handler level by the default handier. Exception handlers being registered with SESAM will not be invoked on the signal 
handler level, but on the user level in the selected invocation mode. For each exception up to three tasks can exist within 
45 SESAM: 

one task for taking care of CbSyncMainDispatch registered callbacks, 
one task for taking care of CbAsyncMainDispatch_SyncSesamDispatch registered callbacks, 
and one task for invoking CbAsyncMainDispatch_AsyncSesamDispatchregistered callbacks. This results in keep- 
50 ing the stack of callbacks for identical invocation modes within one task and sequentially activating each callback. 
The default handler will only put one message into the message queue for each task. 

Figure 1 4 illustrates a stack of user defined system exception handlers separated by invocation modes (within one 
slot, i.e. for one exception). As illustrated, exception handlers registered for the same exception in different invocation 
55 modes may run in parallel since they are located on different stacks. 

Figure 15 illustrates a parallel execution of exception handlers for the same exception. As illustrated, such a design 
also allows for the execution of exception handlers in parallel for different exceptions, if they are registered with using 
callback mode "CbAsyncMainDispatchL-AsyncSesamDispatch.'' All other invocation modes enforce the sequential exe- 
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cution of callbacks (even for different exceptions). 

Figure 16 illustrates serializing exception handler routines by invoking them via the dispatcher 104 (using callback 
modes CbSyncMainDispatch) or dispatcher 108 (using callback modes CbAsyncMainDispatch__SyncSesamDispatch). 
Figure 17 illustrates parallel execution of exception handlers for different exceptions when using callback mode 
5 CbAsyncMainDispatch_AsyncSesamDispatch. 

With each invocation of the default handler, the slot for the appertaining exception will be pulsed, i.e. set and reset. 

Signaled state 

10 Figure 18 illustrates a signaled state of an exception slot. As illustrated, Synch Handles for exception slots are 

always valid, i.e. can always be used in waitFor...O calls. 

The default handler is responsible for detection, if invoked for the first time on signal level, or repeatedly invoked by 

cooperative signal handlers from third party libraries. If invoked repeatedly (i.e., an endless loop), the default handler 

just returns without executing further activities. 
is Upon installation of the default handler, already installed handlers of third party software must be chained along 

with all other registered callbacks and not discarded. 

The installation mode of default handlers "SA_RE START and "SA_NO RESTART will depend on the installation 

mode of third party library handlers found upon installation time. Default handler should always be installed in the same 

mode as previously registered third party library handlers. Third party library handlers may not have conflicting installa- 
20 tion modes. 

Third party libraries may not uninstall signal handlers at runtime (since they most likely will uninstall the default han- 
dler). 

Installation of a default signal handler for a specific signal is only needed if the first callback is registered to this sig- 
nal (either explicitly by registerO or implicitly by using waitFor..()). 
25 Message queue manipulations within the tasks for each exception must use signal guards in order to prevent dead- 
locks. 

For safety purposes, within each thread that is active at the signal handler level, a thread specific storage entry is 
set to indicate execution at the signal handler level. This entry allows for checking within non-exception safe functions 
as to whether they are invoked correctly or not. If invoked at the exception level, they may return an error. Setting and 
30 resetting of this thread specific storage entry is the responsibility of appertaining handle_...0 routines providing the 
environment for subsequently invocations of registered callbacks. 

Upon entry into the default signal handler the thread specific error from the user level must be saved (to prevent an 
overwrite of the error) and restored before leaving the handler (so that the data is again available at the user level). 
An exception handler is removed at the time the "remove" call is issued even if there are exceptions still pending for 
35 this handler. 

The "registerExceptionHandlerO" interface allows the specification of hooks to be invoked before the exception call- 
back is activated (beforeCb component) and after the exception callback has returned (afterCb component). The hook 
functions will be invoked in the same thread in which the exception callback is invoked. 

40 GENERAL SYNCHRONIZATION INTERFACE 

Synchronization on completion of parallel activities is an important issue (e.g. wait until either SynchHandle 1 or 
SynchHandle 2 is f inished-but not longer than a fixed amount of time). To relieve the application programmer from this 
error prone job, a generic slot concept is provided within SESAM that allows the usage of a homogenous waitFor... 0 

45 interface for all kinds of events. 

Since event propagation within a software architecture, such as CSA, is implemented by means of objects or 
classes such as CsaConnectables and CsaRemotes, they internally use the generic slot interface of the SESAM in 
order to provide the user with the possibility of waiting for (i.e., synchronize on) any user events. CsaConnectables and 
CsaRemotes are internally connected with the underlying basic communication system ("bcs" which is invisible to the 

so user). For more information on these objects/classes please refer to the commonly assigned and copending applica- 
tions referred to above which are incorporated herein by reference. 

A generic slot can be created, deleted, set to signaled state, reset from signaled state and pulsed (implicitly set / 
reset signaled state). Since a generic slot has a SynchHandle assigned to it, it can be waited for. This extends the appli- 
cation range of the waitFor... 0 call to any user event. 

55 A generic slot is interconnected to a combination of "CsaConnectable" (i.e. supplier of an user event) and bcs 
object or to a combination of bcs object and "CsaRemote" object (i.e. consumer of an user event). 
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A generic slot will be created by a bcs object every time a CsaConnectable registers with it. This generic slot is 
assigned to the newly registered CsaConnectable exclusively. The CsaConnectable can query the SynchHandle from 
5 its bcs, if needed. 

Figure 19 illustrates an interconnection between a CsaConnectable, a generic slot and a bcs object. As illustrated, 
the generic slot assigned to a CsaConnectable will be pulsed whenever a reply for this CsaConnectable is received. 
waitFor...O on the SynchHandle for a CsaConnectable allows to wait for any reply coming into this CsaConnectable. 

The creation of generic slots for CsaRemotes and CsaConnectables upon registration can be enabled/disabled at 
10 the bcs object during process startup. 

Consumer connection 

A generic slot will also be created by a bcs object every time a CsaRemote registers with it. This generic slot is 
is assigned to the newly registered CsaRemote exclusively. The CsaRemote object can query the SynchHandle from its 
bcs, if needed. 

Figure 20 illustrates a Interconnection between a CsaRemote object, a generic slot and a bcs object. As illustrated, 
a generic slot assigned to a CsaRemote object will be pulsed whenever an update was received by the CsaRemote 
(push mode) or whenever any getValueO call succeeded with this CsaRemote (pull mode). 
v The creation of generic slots for CsaRemotes and CsaConnectables upon registration can be enabled/disabled at 
the bcs object during process startup. 

Control interface 

25 There is no support for suspend / resume methods on generic slots. 
Signaled state 

With each reply being received by the bcs object and transferred to the CsaConnectable, the generic slot is pulsed. 
30 Figure 21 illustrates a signalled state of a CsaConnectable. 

For the CsaRemote slot signaling will depend on the operation mode (Push/Pull): 

Pull Mode 

The bcs object will pulse the generic slot for a CsaRemote in pull mode whenever a getValueO call succeeded 
35 for this CsaRemote object. 

Figure 22 illustrates a Signaled state of a CsaRemote in Pull mode. 

Push Mode: 

w The bcs object will pulse the generic slot (set / reset) with each event (update) being received for this CsaRe- 

mote before the callback is activated. 

Figure 23 illustrates a Signaled state of a CsaRemote in Push mode. 

If a CsaConnectable / CsaRemote is destroyed, its generic slot state is invalid, i.e. it can't be used in a wartFor...() 
45 call any more in future. Any waitFor...O calls that are waiting for an event in any logical combination will be aborted and 
return an error at that moment when the according CsaConnectable / CsaRemote is removed. 

Hooks 

so No hooks are provided for generic slots. 

Although modifications and changes may be suggested by those skilled in the art, it is the intention of the inventors 
to embody within the patent warranted hereon all changes and modifications as reasonably and properly come within 
the scope of their contribution to the art. 

55 Claims 

1 . An object oriented computing system programmer interface system on a computer platform, comprising: 
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m. 

(a) at least one dynamic slot providing asynchronous execution of programmer submitted functions; 

(b) at least one synchronous timer slot; 

(c) at least one asynchronous timer slot; 

(d) at least one exception slot for handling programmer defined system exception callbacks; 
5 (e) at least one slot providing external event notification for programmer events; 

(f) a thread dispatcher; 

(g) a main dispatcher; 

(h) a signaling dispatcher; 

(i) a thread manager for managing execution of threads required by a slot; 
w 0) message block memory for storage of message blocks; 

(k) a list of activity identifiers that return an error external event notification for user events; 
(I) an administrator for mapping of the activity identifiers to slot identifiers; and 
(m) a queue for blocked threads. 

is 2. The object oriented computing system programmer interface system according to claim 1 , wherein a plurality of 
dynamic slots are provided, and the dynamic slots are configured to assume the following states: 

an initial state when nonsignalled and not yet used; 
a queued state when nonsignalled and in use; 
20 a started state when nonsignalled and in use and a submitted function is being executed; 

a finished state when signalled and in use and execution of a submitted function is complete; 

a callback active state when signalled and in use and a submitted function is being executed; and 

an idle state when signalled and no longer in use, wherein a signalled state is assumed when a programmer 

submitted function has been executed. 

25 . 

3. The object oriented computing system programmer interface system according to claim 1 ore 2, wherein the main 
dispatcher is provided by way of a pointer to an operating system dispatcher. 

4. An object oriented computing system programmer interface system, comprising: 

means for centrally dispatching threads and providing runtime configurable delivery of event handlers; 
means for interrupting execution of event handlers; 
means for blocking waits for events in event handlers; 

means for executing functions asynchronously with respect to events occurring external to the interface sys- 
35 tern; and 

means for executing asynchronous timer handlers in parallel to other running event handlers. 

5. An object oriented computing system programmer interface system, comprising: 

40 means for interrupting callback driven systems, including interrupting callbacks themselves; 

an asynchronous dispatcher ; 
a synchronous dispatcher; 
an asynchronous signaling dispatcher; 
a thread manager; and 

45 a plurality of different types of slots used for administrating activities assigned to them. 

6. The object oriented computing system programmer interface according to claim 5 wherein said plurality of different 
types of slots comprises: 

so at least one dynamic slot which administrates asynchrony for an application programmer; 

at least one synchronous timer slots which administrates synchronous timers; 
at least one asynchronous timer slot which administrates asynchronous timers; 
at least one exception slot which administrates user defined system exception callbacks; and 
at least one generic slot which administrates wartFor...Q functionality for user events. 
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A storage medium including object oriented code having an object oriented computing system programmer inter- 
face system on a computer platform, comprising: 
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, (a) at least one dynamic slot providing asynchronous execution of programmer submitted functions; 

(b) at least one synchronous timer slot; 

(c) at least one asynchronous timer slot; 

(d) at least one exception slot for handling programmer defined system exception callbacks; 
5 (e) at least one slot providing external event notification for programmer events; 

(f) a thread dispatcher; 

(g) a main dispatcher; 

(h) a signaling dispatcher; 

(i) a thread manager for managing execution of threads required by a slot; 
io (j) message block memory for storage of message blocks; 

(k) a list of activity identifiers that return an error external event notification for user events; 
(I) an administrator for mapping of the activity identifiers to slot identifiers; and 
(m) a queue for blocked threads. 



15 8. The storage medium according to claim 7, wherein a plurality of dynamic slots are provided, and the dynamic slots 
are configured to assume the following states: 



an initial state when nonsignalled and not yet used; 
a queued state when nonsignalled and in use; 
20 a started state when nonsignalled and in use and a submitted function is being executed; 

a finished state when signalled and in use and execution of a submitted function is complete; 

a callback active state when signalled and in use and a submitted function is being executed; and 

an idle state when signalled and no longer in use, wherein a signalled state is assumed when a programmer 

submitted function has been executed. 

25 

9. The storage medium according to claim 7 or 8, wherein the main dispatcher is provided by way of a pointer to an 
operating system dispatcher. 



10. A storage medium including object oriented code having an object oriented computing system programmer inter- 
30 face system, comprising: 

means for centrally dispatching threads and providing runtime configurable delivery of event handlers; 
means for interrupting execution of event handlers; 
means for blocking waits for events in event handlers; 
35 means for executing functions asynchronously with respect to events occurring external to the interface sys- 

tem; and 

means for executing asynchronous timer handlers in parallel to other running event handlers. 

11. A storage medium including object oriented code having an object oriented computing system programmer inter- 
na face system, comprising: 



means for interrupting callback driven systems, including interrupting callbacks themselves; 
an asynchronous dispatcher ; 
a synchronous dispatcher; 
45 an asynchronous signaling dispatcher; 

a thread manager; and 

a plurality of different types of slots used for administrating activities assigned to them. 
12. The storage medium according to claim 1 1 wherein said plurality of different types of slots comprises: 

50 

at least one dynamic slot which administrates asynchrony for an application programmer; 
at least one synchronous timer slots which administrates synchronous timers; 
at least one asynchronous timer slot which administrates\asynchronous timers; 
at least one exception slot which administrates user defined system exception callbacks; and 
55 at least one generic slot which administrates waitFor...Q functionality for user events. 
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